Why you generally shouldn’t use shared objects
If shared objects are such an important part of the Progress language, why shouldn’t you use them? The reason has a lot to do with the persistent procedures you’ve been learning about in this chapter and which form the basis for most modern application code.
It is possible to share an object between a main procedure and a persistent procedure that it runs. But this would normally be a very unwise thing to do. Once your code runs a persistent procedure, any other procedure in the application with access to its handle can make use of its internal entries. And those procedures won’t be able to use the shared object because they have no relationship on the procedure call stack to the persistent procedure. So the notion of a fixed parent-child relationship between one procedure and another is no longer there. In a modern, event-driven application, it is better to think of the various running procedures as peers cooperating together rather than as a hierarchy. You can use shared objects only in a fixed hierarchy, so shared objects are no longer an appropriate way to pass data from one object procedure to another.
Figure 13–10 shows a diagram of persistent procedures with another procedure added to the mix, just as a simple illustration.
MainProc.p runs both SubProc.p and OtherProc.p as persistent procedures. It passes SubProc.p’s procedure handle to OtherProc.p as a parameter (or makes it available in some other way). Now OtherProc.p can make use of the internal entries in SubProc.p by running them in its procedure handle. But there’s no other relationship between OtherProc.p and SubProc.p because they were run independently. So, there’s no way they could make use of shared objects between them. This is the heart of why shared objects are now a problematic concept in event-driven applications and why you should generally avoid them.
Another reason why shared objects are of limited value in a modern application is that new applications are likely to be distributed across multiple machines and separate OpenEdge sessions. While you can pass most types of objects as parameters between sessions and between machines using the OpenEdge AppServer, there is no way to make use of the SHARED construct between sessions. This means that if you have two procedures today that use shared objects and tomorrow you decide that in your revised application architecture they should run on separate machines, you will have a lot more work to do to change the code so that it doesn’t use the shared objects than you would if the data were already passed as parameters between the procedures. In general, code with many shared objects represents one of the biggest challenges for developers migrating existing older applications to a newer architecture.
Does this mean you should never use shared objects in a new application? The construct is still there and is still supported, for the sake of backward compatibility, but it is a good practice not to make use of it. Shared objects provide few advantages and several potential disadvantages to the future evolution of your code compared to other Progress constructs available to you today.